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The  New  Department  of  Defense  Instruction  5000.02 


-  DEPSECDEF  Direction  - 


I  am  directing  the  Under  Secretary  of  Defense  for  Acquisition,  Technology,  and  Logistics 
(USD(AT&L)),  with  the  Department  of  Defense  Chief  Information  Officer  and  the  Director, 
Operational  Test  and  Evaluation,  to  jointly  prepare  a  revised  DoDI  5000.02  within  1 80  days. 

The  USD(AT(S£;L)  will  draft  a  new  instruction  to  address  acquisition  of  services  in  the  same  time 
period. 


The  New  Department  of  Defense  Instruction  5000.02 

-  USD  (AT&L)  Memo  -2  December  2013  - 

...  developing  a  legislative  proposal  that  will  simplify  the  existing  body  of  law 

Program  structures  should  always  be  tailored  to  the  product  being  acquired. 

The  basic  structure  ...  unchanged  with  minor  exceptions  ...  introduces  a  “Req’ts 
Decision  Point  and  “Development  RFP  Release  Decision  Point  ” 

The  new  Requirements  Decision  Point . . .  starting  point  for  the  requirements  anaiysis 
and  ailocation  system  engineering  process  . . .  cuiminates  in  PDR. 

The  Deveiopment  RFP  Release  Decision  Point  institutionalizes  ...  “Pre-EMD  Review” 
. . .  most  important  singie  decision  point  in  the  entire  iife  cycie  . . .  sets  in  motion 
everything  that  wiil  foliow  in  the  product’s  iife  cycie. 

. . .  provided  the  opportunity  to  integrate  several  of  the  BBP  initiatives 

...  integration  of  req’ts  and  acquisition  is  emphasized 

...  developing  affordability  constraints  is  a  req’ts  &  programming  community 
responsibility  -  not  acquisition  community  or  a  cost  estimator  responsibility 

AEs,  PEOs  and  PMs  are  responsible  and  accountable  . . .  everyone  else  has  a 
supporting  or  advisory  role 


If  you  have  an  ideas  about  how  to  improve  this  guidance,  you  are  encouraged  to 
submit  them. 


DoDI  5000.02  Overview 


•  Core  Instruction 

•  13  Enclosures 

•  ALL  Enclosures  have 
been  Revised... 

•  New  Enclosures  are 
highlighted  in  Red 

•  Old  Enclosures  with 
Major  Revisions  are 
highlighted  in  Blue 

•  150  Pages 


Revised  DoDI  5000.02  Structure 

Core  Instruction  -  Operation  of  the  Defense  Acquisition 
System 

Enclosures 

1.  Acquisition  Program  Categories  and  Compliance 
Requirements 

2.  Program  Management 

3.  Systems  Engineering 

4.  Deveiopmental  Test  and  Evaiuation  (DT&E) 

5.  Operational  and  Live  Fire  Test  and  Evaluation 

6.  Life-Cycle  Sustainment  Pianning 

7.  Human  Systems  Integration  (HSI) 

8.  Affordabiiity  Anaiysis  and  Investment  Constraints 

9.  Analysis  of  Alternatives 

10.  Cost  Estimating  and  Reporting 

11.  Requirements  Appiicable  to  AM  Programs  Containing 
Information  Technology  (IT) 

12.  Defense  Business  Systems  (DBS) 

13.  Rapid  Acquisition  of  Urgent  Needs 


Overarching  Objectives 


•  Decrease  emphasis  on  “rules”  and  increase  emphasis  on 
process  intent  and  thoughtful  program  planning 

•  Provide  program  structures  and  procedures  tailored  to  the 
dominant  characteristics  of  the  product  being  acquired  and  to 
unique  program  circumstances,  e.g.,  risk  and  urgency 

•  Enhance  the  discussion  of  program  management  responsibility 
and  key  supporting  disciplines 

•  Institutionalize  changes  to  statute  and  policy  since  the  last 
issuance  of  DoD  Instruction  5000.02  in  December  2008 
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Figure  1  iHustrates  the  sequence  of  decision  events  in  a  generic  program, 
it  is  not  intended  to  refiect  the  time  dedicated  ro  associated  phase  activity. 
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•  CDD  Validation  precedes  Development  RFP  Release  Decision  Point  and  provides 
basis  for  preliminary  design  activities  and  PDR 

•  Active  engagement  between  acquisition  and  requirements  leadership  of  the  proposed 
requirements  is  essential  to  ensure  validated  requirements  address  priorities  in 
affordable  way 

•  Acquisition  leadership  will  participate  in  validation  authorities’  review  and  staffing  of 
CDD  prior  to  validation  to  ensure  requirements  are  technically  achievable,  affordable 
and  testable,  and  fully  informed  by  systems  engineering  trade-off  analyses 
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•  Development  RFP  Release  Decision  Point  is  to  ensure  that  executabie  and  affordabie 
program  has  been  planned  using  a  sound  business  and  technical  approach 

•  Critical  decision  point ...  program  will  either  successfully  lead  to  fielded  capability  or 
fail,  based  on  soundness  of  capability  requirements,  affordability,  and  executability 

•  Authorizes  release  of  RFP  for  EMD  and  often  LRIP  options 

•  Sets  in  motion  all  that  will  follow  ...  last  point  at  which  significant  changes  can  be  made 
without  major  disruption 


Defense  Acquisition  University 


Product-Tailored  Acquisition  Models 

Models  are  not  intended  to  be  restrictive  in  nature  --  designed 
as  a  starting  point  for  program  planning 


KM  Model  1:  Hardware  Intensive  Program 
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•  “Classic”  model  that  has  existed  in  some  form  in  aii  previous  editions 

•  Hardware  intensive  deveiopment  such  as  a  major  weapon  systems  piatform 

•  Starting  point  for  most  weapon  systems;  however,  aimost  aiways  contain  software 
deveiopment  resuiting  in  some  form  of  Hybrid  Modei  A 


Model  2:  Defense  Unique 
Software  Intensive  Program 
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*  Dominated  by  need  to  develop  complex,  usually  defense  unique,  software  program 
that  will  not  be  deployed  until  several  software  builds  completed 

*  Key  feature  is  planned  s/w  builds  -  series  of  testable,  integrated  capability  subsets  - 
which  together  with  clearly  defined  decision  criteria,  ensure  adequate  progress  before 
fully  committing  to  subsequent  builds 

*  Examples:  military-unique  command  and  control  systems  and  upgrades  to  combat 
systems  on  weapons  systems  such  as  surface  combatants  and  tactical  aircraft 


Model  3:  Incrementally  Fielded 
Software  Intensive  Program 
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Rapid  delivery  of  capability  using  several  limited  fieldings  in  lieu  of  single  MS-B  and  C 
and  single  full  deployment 

Several  builds  and  fieldings  typically  needed  to  satisfy  approved  req’ts  for  increment 

Applicable  for  COTS  software,  such  as  commercial  business  systems  with  multiple 
modular  capabilities,  are  adapted  for  DoD 


KM  Hybrid  Program  A  (Hardware  Dominant) 
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Depicts  how  a  major  weapons  system  combines  h/w  deveiopment  as  basic  structure 
with  s/w  intensive  development  occurring  simuitaneousiy 

Design,  fab,  and  testing  of  physical  prototypes  may  determine  overall  schedule, 
decision  points,  and  miiestones,  but  software  development  often  dictates  pace  of 
program  execution  and  requires  tight  integration 

Builds  should  lead  to  full  capability  needed  to  satisfy  requirements  and  iOC 

Milestone  B/C  decisions  inciude  software  functional  capability  deveiopment  maturity 
criteria  as  weli  as  demonstrated  technical  performance  exit  criteria 


Hybrid  Program  B  (Software  Dominant) 
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Depicts  how  s/w  intensive  product  development  can  include  mix  of  incrementally 
fielded  software  products  or  releases  that  include  intermediate  software  builds 


Risk  Management:  Highly-integrated,  complex  s/w  &  h/w  development  risks  must  be 
managed  throughout  life  cycle  -  special  interest  at  decision  points  and  milestones 


Model  4:  Accelerated  Acquisition  Program 
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Materiei  Concurrent  Technology  Concurrent  Operations  &  Support 

Soiution  Maturation,  Risk  Reduction  Production  and 
Anaiysis  and  Deveiopment  Depioyment 


•  Applies  when  schedule  dominates  over  cost  and  technical  risk  considerations 

•  Compresses  or  eliminates  phases  accepting  potential  for  Inefficiencies  in  order  to 
achieve  deployed  capability  on  compressed  schedule 

•  Model  shows  one  example  of  tailoring  with  many  others  possible  for  products  that 
must  be  developed  and  acquired  ASAP,  usually  motivated  by  potential  adversary 
achieving  technological  surprise,  and  featuring  greater  acceptance  of  program  risk 


Acquisition  Program  Categories  &  Compiiance 
Requirements  (Enclosure  1) 


•  New  ACAT  definitions  based  on  FY2014  constant  doliars 

-  ACAT  I:  >  $480M  in  RDT&E  or  $2.79B  in  procurement 

-  ACAT  il;  >  $185M  in  RDT&E  or  $835M  in  procurement 

-  ACAT  iA:  >  $40M,  ali  expenditures  in  single  year 

>  $165M,  ail  expenditures  from  Materiei  Solution  Phase  to 
deployment 

>  $520M,  all  expenditures  from  Materiel  Solution  Phase  to 
estimated  useful  life  of  the  system 

•  One  “stop  shopping”  for  Category  and  Compliance  information 
in  tabular  format 

-  Consolidates  information  from  various  locations  in  prior  5000.02  and  other 
regulations 


Acquisition  Program  Categories  &  Compliance 
Requirements  (Enclosure  1) 

•  Nine  Tables: 

-  Table  1 :  Description  and  Decision  Authority  for  ACAT  l-ili  Programs 

-  Table  2:  Milestone  &  Phase  Information  Requirements 

-  Table  3:  APBs  (Baseline  and  Deviations) 

-  Table  4:  Statutory  Program  Breach  and  Change  Definitions 

-  Table  5:  Recurring  Program  Reports 

-  Table  6:  Exceptions,  Waivers,  and  Aiternative  Reporting  Requirements 

-  Table  7:  CSDR  System  Requirements 

-  Table  8:  EVM  Requirements 

-  Table  9:  Clinger-Cohen  Act  (CCA)  Compliance 


Acquisition  Program  Categories  &  Compliance 
Requirements  (Enclosure  1) 


All  requirements  listed  in  alphabetical  order. 
STATUTORY  items  in  ALL  CAPS 

Notes  identify  the  requirement  as  STATUTORY 
or  Regulatory 


Table  2.  iMilegtoue  aad  Phase  Information 


A  dot  (•)  in  a  cell  indicates  applicability  of  the  requirement  to  program  type 
and  life-cycle  event,  and  represents  the  initial  submission  requirement. 
Moving  right  across  a  row,  a  checkmark  (V)  indicates  the  requirement  for 

updated  information. 
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•  Notes  accompany  most  rows  to  explain  the  requirement,  limit  or 
extend  the  requirement's  applicability  to  program  type  and/or  life- 
cycle  event(s),  or  explain  any  special  conditions. 

A  new  column  identifies  the  Approval  Authority. 


Program  Management  (Enclosure  2) 


•  Acquisition  Chain  of  Command  and  PEO  and  PM  Assignments 

•  Program  Management  Responsibiiities 

•  Program  Office  Structure  and  Organizations 

•  Acquisition  Strategies 

-  Business  Approach  and  Risk  Management 

-  Competition 

-  Intellectual  Property  (IP)  Strategy  and  Open  Systems/Architectures 

•  Program  Baseline  Development  and  Management 

•  Program  Management  Tools 

-  Earned  Value  Management  (EVM) 

-  Risk  Management 

-  Cost  Baseline  Control  and  Use  of  “Should  Cost”  Management 

•  International  Acquisition  and  Exportability 

•  Industrial  Base  Analysis  and  Considerations 

•  Life-cycle  Management  of  Information  and  Data  Protection 


Systems  Engineering  (Enclosure  3) 


•  Sections  (new  sections  in  Red) 

1 .  Purpose 

2.  System  Engineering  Plan 

3.  Development  Planning 

4.  Systems  Engineering  Trade-Off  Analyses 

5.  Technical  Risk  and  Opportunity  Management 

6.  Technical  Performance  Measures  and  Metrics 

7.  Technical  Reviews 

8.  Configuration  Management 

9.  Modeling  and  Simulation 

10.  Manufacturing  and  Producibility 

1 1 .  Software 

12.  Reliability  and  Maintainability  (R&M) 

13.  Program  Protection 

14.  Open  Systems  Architectures 

15.  Corrosion  Prevention  and  Control 

16.  ESOH 

17.  Insensitive  Munitions 

18.  Item  Unique  Identification 

19.  Spectrum  Supportabiltiy 

20.  Design  Reviews 

21.  Program  Support  Assessments  (PSAs) 


Systems  Engineering  (Enciosure  3) 


•  Systems  engineering  trade-off  analysis  required  to  support  CDD  Validation  DP 

•  Reassessed  over  life  cycle  as  system  requirements,  design,  manufacturing,  test  and 
logistics  activities  mature  and  evolve 

•  Technical  risk  management  goal  is  to  both  “mitigate  risks  and  create 
opportunities”  for  tech  development  that  have  positive  impact  on  performance 
objectives  and  thresholds 

•  Program  Protection 

-  Integrating  process  for  managing  risks  to  DoD  warfighting  capability  from  foreign 
intelligence  collection;  hardware  or  software,  and  cyber  vulnerability  or  supply  chain 
exploitation;  and  battlefield  loss  throughout  program  life  cycle 

-  Program  Managers  will  submit  program’s  Component  CIO-approved  Cybersecurity 
Strategy  as  part  of  every  Program  Protection  Plan  (PPP) 

-  PPP  submitted  for  MDA  approval  at  each  M/S  review,  beginning  with  MS-A 

-  For  MDAPs  at  MS-B,  DoD  Component-approved  draft  PPP  provided  to  DASD(SE)  45 
days  prior  to  Development  RFP  Release  Decision  Point 


Developmental  Test  and  Evaluation  (End  4) 


•  Chief  Developmental  Tester  for  MDAPs  and  MAISs 

•  Lead  DT&E  (Government)  Organization  for  MDAPs 

•  TEMP  at  all  Milestones  (no  more  Test  &  Evaluation  Strategy  at  MS-A) 

•  Major  emphasis  on  use  of  Government  Test  Facilities  (GTF)  as 
preferred  strategy  (GTFs--mandatory  for  software  unless  an  exception  can  be  justified) 

•  Emphasis  on: 

-  Use  of  scientific  and  statistical  rigor  when  developing  T&E  program 

-  Program  Protection  and  Cybersecurity 

-  Interoperability  Testing 

•  Software  test  automation  strategy  to  include  when  key  automation 
software  components  or  services  will  be  acquired  and  how  decisions 
will  be  made  required  in  TEMP  at  MS-A 

•  Reliability  Growth  Curve(s)  included  in  the  MS-B  TEMP  (updated  in  all 
future  TEMPs) 

•  For  accelerated  acquisition  and  urgent  programs,  levels  of 
developmental  testing  required  will  be  highly  tailored  to  emphasize 
schedule  over  other  considerations 


Operational  and  Live  Fire  T&E  (End  5) 


•  OT&E  planning  moved  to  left 

-  T&E  WIPT  formed  at  MOD  or  as  soon  as  practical 

-  OTAs  comment  on  OT&E  implications  of  CONOPs  after  MOD 

-  TEMP  at  all  Milestones  (no  more  Test  &  Evaluation  Strategy  at  MS-A) 

-  Metrics  on  completeness  of  design  information  in  MS-A  TEMP 

•  New  section  on  Software  Testing 

-  Plan  for  use  of  system  logs  starting  at  MS-B 

-  Demonstration  of  end-to-end  regression  testing  at  or  before  lOT&E 

-  Demonstration  that  maintenance  test  environment  replicates  operations 
environment  at  or  before  lOT&E 

-  Includes  definition  for  risk-based  OT&E  and  interoperability 

-  Full  lOT&E  prior  to  Full  Deployment  Decision  for  incrementally  fielded 
software  intensive  programs 


•  Program  Manager  will  develop  and  implement  affordable  and  effective 
performance-based  product  support  strategy 

-  stronger  emphasis  on  “affordable” 

-  Requirement  to  drive  competition  at  both  the  prime  and  subcontract  leveis 

•  Empioy  “Should-Cost”  management  and  analysis  approach  to 
identify  and  implement  system  and  enterprise  sustainment  cost 
reduction  initiations 

•  Life-Cycie  Sustainment  Pian  (LCSP)  --  Required  for  ALL  programs, 
updated  at  each  decision  point,  starting  with  MS-A  (if  appiicabie) 

-  Updated  at  a  minimum  of  every  5  years  post  Initial  Operational  Capability  (IOC) 

•  Sustainment  Metrics  -  Avaiiability  (KPP),  Materiai  Reiiabiiity, 
Operating  and  Support  Cost,  Mean  Down  Time.. .others  as  needed 

-  Tied  to  ongoing  Should  Cost  analysis 


Human  System  lntegration(Enclosure  7) 


•  The  Program  Manager  will  plan  for  and  implement  Human 
System  Integration  (HSi)  beginning  eariy  in  the  acquisition 
process  and  throughout  the  product  life  cycle.  Addressing: 

-  Human  Factors  Engineering 

-  Personnel 

-  Habitability 

-  Manpower  (Miiitary/Civ/Contractor  Mix) 

-  Training 

-  Safety  and  Occupationai  Heaith 

-  Force  Protection  and  Survivability 


Affordability  Analysis  and  Investment 
Constraints  (Enclosure  8) 


•  Responsibility  for  DoD  Component  Leadership 

-  Involves  programming,  resource  planning,  requirements,  intelligence,  and 
acquisition  communities 

•  Required  for  entire  life  cycle  of  planned  system,  not  just  FYDP 

•  Constraints  are  developed  “top  down” 

-  As  compared  to  cost  estimates  which  are  generated  bottoms  up  or  by  other 
methods 

•  Life  Cycle  Affordability  Analysis  -  required  for  all  ACAT I  and  lA 
programs  at  Component  level  --  includes  their  entire  portfolio  groups 
in  reasonable  categories.  Considerations: 

-  Future  Budget,  Time  horizon  (nominaliy  30-40  years),  current  fiscai  guidance, 
OSD  infiators...etc 

-  Subdivided  into  Portfolios  to  facilitate  Trade  off  Analysis 

•  CAE  will  manage  lower  ACAT  programs  similarly 

“Department  has  a  long  history  of  starting  programs  that  proved  to  be  unaffordable” 


Analysis  of  Alternatives  (Enclosure  9) 


•  Director  of  Cost  Assessment  and  Program  Evaluation  (DCAPE) 
develops  and  approves  study  guidance  for  AoA  for  potential  and 
designated  ACAT I  and  lA  programs  and  for  each  joint  military  or 
business  requirement  for  which  Chairman  of  the  Joint 
Requirements  Oversight  Council  (JROC)  or  Investment  Review 
Board  is  validation  authority.  DCAPE  will  require,  at  a  minimum 

-  Full  consideration  of  possible  tradeoffs  among  life-cycle  cost,  schedule, 
and  performance  objectives  (including  mandatory  key  performance 
parameters)  for  each  aiternative  considered 

-  Assessment  of  whether  joint  miiitary  requirement  can  be  met  in  manner 
consistent  with  cost  and  scheduie  objectives  recommended  by  JROC  or 
other  requirements  vaiidation  authority 

Consideration  of  affordability  analysis  results  and  affordability  goals  if 
established  by  MDA 


Cost  Estimating  and  Reporting  (End  10) 

•  DCAPE  conducts  Independent  Cost  Estimates  (ICE)  for  MDAPs/MAIS  for  which 
USD(AT&L))  is  MDA  or  as  requested  for  other  MDAPs/MAiS  programs 

-  In  advance  of  any  LRIP  or  Full  Rate  Production,  when  required  by  Title  10,  upon  request 
of  MDA,  or  when  DCAPE  considers  it  appropriate 

•  Very  specific,  detaiied  instructions  for  DCAPE  to  be  proactive  with  continuai 
program  invoivement.  For  exampie: 

-  DCAPE  must  be  with  service  representatives  and  the  program  office  NLT 180  day  prior  to 
Development  RFP  Release,  and  will  then  determine  cost  analysis  to  be  accomplished. ...is 
granted  full  access  to  all  data.. .etc. 

•  Cost  Analysis  Requirements  Description  (CARD) 

-  Prepared  by  PM--draft  presented  to  DCAPE  NLT  180  days  prior  to  planned  DIPT  meeting 

-  Final  version  due  45  days  before  meeting 

-  Required  updates  prior  to  Development  RFP  Release  Point,  in  addition  to  MS  reviews 

-  More  detailed  as  program  moves  from  Milestone  A  to  B  to  C... 

•  Cost  Reporting 

-  Continue  to  use  Cost  and  Software  Data  Reporting  (SCDR),  Integrated  Program 
Management  Reports  as  primary  sources 

-  Visibility  and  Management  of  Operating  and  Support  Costs  (VAMOSC)  systems  must 
include  all  support  materials  used  for  cost  estimates  --  information  reviewed  annually 


Tec^in(o'[(3'5T  (l-f 


'jre 


•  Clinger-Cohen  -  still  applies  to  all  IT  investments  including  NSS  --  Compliance 
Requirements  Table  moved  to  Enc  1 

•  Clinger-Cohen  requirement  for  DoD  CIO  confirmation  for  MDAPs/MAISs  removed 

-  Sponsoring  Component/PM  satisfies  requirements  with  Component  CIO  confirmation 

•  Post  Implementation  Reviews  (PIR) 

-  Who:  Sponsoring  Component  CIO  and  PM 

-  What:  Has  desired  capability  been  met? 

-  When:  After  IT  deployed 

-  Why:  Continuation,  modernization,  or  termination  decision 

•  Cybersecurity  strategy  required  at  MS  A  as  Appendix  to  Program  Protection  Plan 

-  DoD  CIO  approval  required  for  ACATS  ID,  lAM,  and  lAC 

-  Risk  management  framework  initiated  as  early  as  possible 

•  Cloud  Computing  -  DISA  is  the  DoD  Enterprise  Cloud  Service  Broker 

-  PMs  coordinate  use  of  cloud  computing  services  through  DISA 

•  DoD  Data  Center  Consolidation 

-  DoD  CIO  must  approve  funds  for  data  services  or  data  centers 

-  PM  requests  use  through  Component  CIO 

-  Implementation  guidance  available  in  Defense  Acquisition  Guidebook 


Defense  Business  Systems  (DBS)  (End  12) 

•  Definition  of  DBS  unchanged  --  stiii  appiicabie  for  DBS  efforts  >  $1 M 

•  Business  Capabiiity  Definition  (BCD)  approvai  precedes  MDD 

-  DBS  requirements  generally  not  generated  via  JCIDS 

•  BCD  Probiem  Statement  serves  as  capabiiity  requirements  document  (ICD) 

-  Approved  by  Investment  Review  Board  (IRB)  Chair 

•  DBS  Investment  Management  Process  Guidance  provides  additionai  detaii  on 
process,  aiong  with  roies  and  responsibiiities 

•  DBS  wiii  empioy  one  of  the  draft  modeis  or  effective  variant  approved  by  MDA 

•  Miiestone/Decision  Point  review  requirements  when  MDA  is  at  OSD  --  CAE  wiii: 

-  Sign  Business  Case 

-  Assure  solution  compliant  with  statutes  and  regulations 

-  Recommend  solutions  to  any  applicable  issues 

•  MS-A  (or  deveiopment  start)  to  IOC  must  be  <  5  years 

•  Functional  Sponsor  defines  iOC  prior  to  Deveiopment  RFP  Reiease  Decision  Point 


Rapid  Acquisition  of  Urgent  Needs 

(Enclosure  13) 


•  Applicable  only  to  needs  below  ACAT I  that  can  be  met  in  <  2  years 

•  Funds  will  normally  have  to  be  reprioritized/reprogrammed  since 
PPBE  process  not  appropriate  for  rapid  acquisition 

•  Types  of  Urgent  Needs 

-  JUONs/JEONs 

-  Component  specific  UONs 

-  Criticai  Warfighter  Issues  identified  by  Warfighter  Senior  Integration  Group 

-  SECDEF  Rapid  Acquisition  Authority  (RAA)  Determination 

•  “DoD  Components  will  use  all  available  authorities  to  expeditiously 
fund,  develop,  assess,  produce,  deploy  and  sustain...” 

-  “Streamline  strategies  and  oversight” 

-  “parailei  rather  than  sequentiai” 

-  “Formal  milestone  events  may  not  be  required” 

-  “MDA  can  authorize  production  at  same  time  as  deveiopment” 

-  “Regulatory  requirements  wili  be  tailored  or  waivered” 


Rapid  Acquisition  of  Urgent  Needs 

(Enclosure  13) 


•  NLT 1  year  after  rapid  acquisition  enters  Ops  and  Support,  disposition 
anaiysis  held  to  determine 

-  Termination:  Demiiitarization  or  Disposai 

-  Sustainment  for  a  current  contingency  -  retains  priority  of  action 

*  Sustainment  decisions  valid  for  no  more  than  2  years 

-  Transition  to  a  Program  of  Record  --  if  a  needed,  enduring  capabiiity  remains 

*  Table  10  provides  info  requirements  unique  to  Rapid  Acquisition  of 
Urgent  Needs 

-  Assessment  Approach 

-  Course  of  Action  Analysis 

-  Rapid  Acquisition  Analysis 

-  Disposition  Authority  Report  to  CAE 


Takeaways 


•  Still  policy,  but ... 

-  Tone  shifts  from  compliance  to  thoughtful  planning 

-  Tailor  when  appropriate  and  approved 

-  Reasoning  and  real  life  trump  document 

•  System  Engineering  tradeoffs  &  affordability  analyses  are  ever-present  major  themes 

•  Should  Cost  “sprinkled”  throughout  -  making  part  of  the  culture 

•  Different  challenges  for  software  intensive  programs  recognized 

•  Cybersecurity  and  Program  Protection  emphasized 

•  2008  DoDI  5000.02  Services  Acquisition  policy  still  in  effect  until  new  DoDI  developed 

•  Next  Steps... 

-  What’s  applicable  to  me? 

-  Read  section/enclosure  in  detail 

-  Engage  your  service  community 

•  Stay  tuned  ...  more  to  come 

•  Provide  Feedback  as  you  start  to  implement 


